Workflow decision management with heuristics

ABSTRACT

Methods, systems, and computer program products are provided for workflow decision management. Embodiments typically include maintaining a device state history; identifying a device usage pattern in dependence upon the device state history; identifying a derived scenario in dependence upon the device usage pattern; and selecting a heuristic in dependence upon the derived scenario. In typical embodiments, the heuristic has a tolerance. Embodiments also include identifying a workflow in dependence upon the selected heuristic and executing the workflow in dependence upon the tolerance.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The field of the invention is data processing, or, more specifically,methods, systems, and products for workflow decision management.

2. Description of Related Art

Conventional networks contain various networked devices. User's oftenuse the various devices, or adjust particular settings of the devices,in accordance with consistent patterns and scenarios of device usage.Despite routinely using devices according to these consistent patternsand scenarios of device usage, conventional networked devices stilloften require user intervention to change attribute values of a device.It would be advantageous if there were a method of workflow decisionmanagement that used workflows to change in values of device attributesin a network in dependence upon identified patterns of usage andidentified scenarios that did not require user intervention.

SUMMARY OF THE INVENTION

Methods, systems, and computer program products are provided forworkflow decision management. Embodiments typically include maintaininga device state history, identifying a device usage pattern in dependenceupon the device state history, identifying a derived scenario independence upon the device usage pattern, and selecting a heuristic independence upon the derived scenario. In typical embodiments, theheuristic has a tolerance. Embodiments also include identifying aworkflow in dependence upon the selected heuristic and executing theworkflow in dependence upon the tolerance.

In typical embodiments of the present invention, maintaining a devicestate history includes recording a plurality of attribute values for adevice. In many embodiments, identifying a device usage pattern independence upon the device state history includes comparing the devicestate history with a plurality of device usage patterns records. In someembodiments, identifying a derived scenario in dependence upon thedevice usage pattern includes retrieving a derived scenario ID from aderived scenario table.

In typical embodiments, selecting a heuristic in dependence upon thederived scenario is carried out by reading a heuristic ID from a derivedscenario record. In some embodiments, selecting a heuristic independence upon the derived scenario includes retrieving a heuristic IDfrom a heuristic table. In many embodiments, identifying a workflow independence upon the selected heuristic includes retrieving a workflow IDfrom a heuristic record.

In many embodiments, executing the workflow in dependence upon thetolerance is carried out by sending a message to a device. In someembodiments, executing the workflow in dependence upon the tolerance iscarried out by calling a member method in a device class.

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescriptions of exemplary embodiments of the invention as illustrated inthe accompanying drawings wherein like reference numbers generallyrepresent like parts of exemplary embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary data processing system capable of workflowdecision management according to embodiments of the present invention.

FIG. 2 sets forth a block diagram of an exemplary device useful inimplementing workflow decision management according to embodiments ofthe present invention.

FIG. 3 is a block diagram illustrating exemplary data structures usefulin implementing methods of workflow decision management according toaspects of the present invention.

FIG. 4 is a block diagrams illustrating more exemplary data structuresuseful in implementing methods of workflow decision management accordingto aspects of the present invention

FIG. 5 is a block diagram illustrating an exemplary relationship amongthe data structures of FIGS. 3 and 4.

FIG. 6 sets forth a data flow diagram illustrating an exemplary methodfor workflow decision management.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS Introduction

The present invention is described to a large extent in thisspecification in terms of methods for workflow decision management.Persons skilled in the art, however, will recognize that any computersystem that includes suitable programming means for operating inaccordance with the disclosed methods also falls well within the scopeof the present invention. Suitable programming means include any meansfor directing a computer system to execute the steps of the method ofthe invention, including for example, systems comprised of processingunits and arithmetic-logic circuits coupled to computer memory, whichsystems have the capability of storing in computer memory, whichcomputer memory includes electronic circuits configured to store dataand program instructions, programmed steps of the method of theinvention for execution by a processing unit.

The invention also may be embodied in a computer program product, suchas a diskette or other recording medium, for use with any suitable dataprocessing system. Embodiments of a computer program product may beimplemented by use of any recording medium for machine-readableinformation, including magnetic media, optical media, or other suitablemedia. Persons skilled in the art will immediately recognize that anycomputer system having suitable programming means will be capable ofexecuting the steps of the method of the invention as embodied in aprogram product. Persons skilled in the art will recognize immediatelythat, although most of the exemplary embodiments described in thisspecification are oriented to software installed and executing oncomputer hardware, nevertheless, alternative embodiments implemented asfirmware or as hardware are well within the scope of the presentinvention.

Definitions

“802.11” refers to a family of specifications developed by the IEEE forwireless LAN technology. 802.11 specifies an over-the-air interfacebetween a wireless client and a base station or between two wirelessclients.

“API” is an abbreviation for “application programming interface.” An APIis a set of routines, protocols, and tools for building softwareapplications.

“Bluetooth” refers to an industrial specification for a short-rangeradio technology for RF couplings among client devices and betweenclient devices and resources on a LAN or other network. Anadministrative body called the Bluetooth Special Interest Group testsand qualifies devices as Bluetooth compliant. The Bluetoothspecification consists of a ‘Foundation Core,’ which provides designspecifications, and a ‘Foundation Profile,’ which providesinteroperability guidelines.

“CEBus” is an abbreviation for Consumer Electronics Bus. CEBus is anopen international standard for controlling devices over different mediasuch as power line, radio frequency (RF), infrared (IR), coaxial cable,twisted pair, fiber optics and audio/video. The CEBus standard ispromulgated by the Consumer Electronic Manufacturers Association (CEMA),a sector of the Electronics Industries Association (EIA) and describedin 12 standards: the ANSI/EIA-600 series. The CEBus standard describes aphysical design and topology of network media, a protocol for messagegeneration, and a common application language (“CAL”). The CEBusspecification is available for download at http://www.cebus.org.

CEBus provides a Common Application Language (CAL) defined in EIA 600.81that uses an object-oriented model to provide interoperability betweendiverse devices in a networked environment. The CAL specificationdefines a set of classes that provide an interface to the internaloperations of these disparate networked devices. If a function orfeature cannot be mapped well to one of the classes defined in the CALspecification, the CAL specification has set aside a specific range ofclass identifiers for defining special classes.

CAL objects have two important attributes Instance Variables andMethods. Instance Variables contain information about a particular CALobject such as Boolean indications, numeric information,character-string information, and other data. Boolean Instance Variablescan only be set to TRUE or FALSE. As the name implies, numeric InstanceVariables are intended for storage of numbers. The character-string typeInstance Variables provide storage of text. And other data-type InstanceVariables provide storage of other information as a single-dimensionedarray of one or more elements; each element containing the same numberof one or more bytes.

Access to the information contained in CAL Instance Variables isaccomplished through a set of member methods specific to that object.Examples of common methods include: setOn, setOff, setValue, getValue,setArray and getArray. Not all methods are appropriate for each InstanceVariable type. For example, a setOn method is intended for manipulatingBoolean Instance Variables and is therefore undefined for an InstanceVariable of the character-string type.

“Coupled for data communications” means any form of data communications,wireless, 802.11b, Bluetooth, infrared, radio, internet protocols, HTTPprotocols, email protocols, networked, direct connections, dedicatedphone lines, dial-ups, serial connections with RS-232 (EIA232) orUniversal Serial Buses, hard-wired parallel port connections, networkconnections according to the Power Line Protocol, and other forms ofconnection for data communications as will occur to those of skill inthe art. Couplings for data communications include networked couplingsfor data communications. Examples of networks useful with variousembodiments of the invention include cable networks, intranets,extranets, internets, local area networks, wide area networks, and othernetwork arrangements as will occur to those of skill in the art. The useof any networked coupling among television channels, cable channels,video providers, telecommunications sources, and the like, is wellwithin the scope of the present invention.

“HAVi” stands for ‘Home Audio Video interoperability,’ the name of avendor-neutral audio-video standard particularly for home entertainmentenvironments. HAVi allows different home entertainment and communicationdevices (such as VCRs, televisions, stereos, security systems, and videomonitors) to be networked together and controlled from one primarydevice, such as a services gateway, PC, or television. Using IEEE 1394,the ‘Firewire’ specification, as the interconnection medium, HAVi allowsproducts from different vendors to comply with one another based ondefined connection and communication protocols and APIs. Servicesprovided by HAVi's distributed application system include an addressingscheme and message transfer, lookup for discovering resources, postingand receiving local or remote events, and streaming and controllingisochronous data streams.

“HomePlug” stands for The HomePlug Powerline Alliance. HomePlug is anot-for-profit corporation formed to provide a forum for the creation ofopen specifications for high speed home powerline networking productsand services. The HomePlug specification is designed for delivery ofInternet communications and multimedia to homes through the home poweroutlet using powerline networking standards.

The HomePlug protocol allows HomePlug-enabled devices to communicateacross powerlines using Radio Frequency signals (RF). The HomePlugprotocol uses Orthogonal Frequency Division Multiplexing (OFDM) to splitthe RF signal into multiple smaller sub-signals that are thentransmitted from one HomPlug enabled-device to another HomePlug-enableddevice at different frequencies across the powerline.

“HTTP” stands for ‘HyperText Transport Protocol,’ the standard datacommunications protocol of the World Wide Web.

“ID” abbreviates “identification” as used by convention in thisspecification with nouns represented in data elements, so that ‘user ID’refers to a user identification and ‘userID’ is the name of a dataelement in which is stored a user identification.

“LAN” is an abbreviation for “local area network.” A LAN is a computernetwork that spans a relatively small area. Many LANs are confined to asingle building or group of buildings. However, one LAN can be connectedto other LANs over any distance via telephone lines and radio waves. Asystem of LANs connected in this way is called a wide-area network(WAN). The Internet is an example of a WAN.

“LonWorks” is a networking platform available from Echelons. Lon Worksis currently used in various network applications such as appliancecontrol and lighting control. The LonWorks networking platform uses aprotocol called “LonTalk” that is embedded within a “Neuron Chip”installed within Lon Works-enabled devices.

The Neuron Chip is a system-on-a-chip with multiple processors,read-write and read-only memory (RAM and ROM), and communication and I/Osubsystems. The read-only memory contains an operating system, theLonTalk protocol, and an I/O function library. The chip has non-volatilememory for configuration data and for application programs, which can bedownloaded over a LonWorks network to the device. The Neuron Chipprovides the first 6 layers of the standard OSI network model. That is,the Neuron Chip provides the physical layer, the data link layer, thenetwork layer, the transport layer, the session layer, and thepresentation layer.

The Neuron Chip does not provide the application layer programming.Applications for LonWorks networks are written in a programming languagecalled “Neuron C.” Applications written in Neuron C are typicallyevent-driven, and therefore, result in reduced traffic on the network.

“OSGI” refers to the Open Services Gateway Initiative, an industryorganization developing specifications for services gateways, includingspecifications for delivery of service bundles, software middlewareproviding compliant data communications and services through servicesgateways. The Open Services Gateway specification is a java basedapplication layer framework that gives service providers, networkoperator device makers, and appliance manufacturer's vendor neutralapplication and device layer APIs and functions.

“USB” is an abbreviation for “universal serial bus.” USB is an externalbus standard that supports data transfer rates of 12 Mbps. A single USBport can be used to connect up to 127 peripheral devices, such as mice,modems, and keyboards. USB also supports Plug-and-Play installation andhot plugging.

“WAP” refers to the Wireless Application Protocol, a protocol for usewith handheld wireless devices. Examples of wireless devices useful withWAP include mobile phones, pagers, two-way radios, and hand-heldcomputers. WAP supports many wireless networks, and WAP is supported bymany operating systems. Operating systems specifically engineered forhandheld devices include PalmOS, EPOC, Windows CE, FLEXOS, OS/9, andJavaOS. WAP devices that use displays and access the Internet run“microbrowsers.” The microbrowsers use small file sizes that canaccommodate the low memory constraints of handheld devices and thelow-bandwidth constraints of wireless networks.

The “X-10” means the X-10 protocol. Typical X-10 enabled devicescommunicate across AC powerline wiring, such as existing AC wiring in ahome, using an X-10 transmitter and an X-10 receiver. The X-10transmitter and the X-10 receiver use Radio Frequency (RF) signals toexchange digital information. The X-10 transmitter and the X-10 receivercommunicate with short RF bursts which represent digital information.

In the X-10 protocol, data is sent in data strings called frames. Theframe begins with a 4 bit start code designated as “1110.” Following thestart code, the frame identifies a particular domain, such as house,with a 4 bit “house code,” and identifies a device within that domainwith a 4 bit “devices code.” The frame also includes a command string of8 bits identifying a particular preset command such as “on,” “off,”“dim,” “bright,” “status on,” “status off,” and “status request.”

Workflow Decision Management with Derived Scenarios and WorkflowTolerances

Exemplary methods, systems, and products for workflow decisionmanagement, are now explained with reference to the accompanyingdrawings, beginning with FIG. 1. FIG. 1 depicts an exemplary dataprocessing system capable of workflow decision management according toembodiments of the present invention. The exemplary system of FIG. 1includes a number of workflow decision management compliant devicescapable of implementing workflow decision management according toembodiments of the present invention that are connected for datacommunications through a local area network (“LAN”) (103). In theexample of FIG. 1, the exemplary workflow decision management compliantdevices include a personal digital assistant (“PDA”) (104), a computerworkstation (106), a personal video recorder (108), a server (110),personal computer (112), a thermostat (114), a laptop (116), a desk lamp(118), a compact disc player (120), and a telephone (102) are coupledfor data communications through a LAN. The network connection aspect ofthe architecture of FIG. 1 is only for explanation, not for limitation.In fact, systems for workflow decision management according toembodiments of the present invention may implemented with LANs, WANs,intranets, internets, the Internet, webs, the World Wide Web itself, orother connections as will occur to those of skill in the art. Suchnetworks are media that may be used to provide data communicationsconnections between various devices and computers connected togetherwithin an overall data processing system.

In the example of FIG. 1, the PDA (104) is coupled for datacommunications to the LAN (103) through a wireless link (124). TheWorkstation (106), the server (110), the personal computer (112), thelaptop (116), and the telephone (102) are coupled for datacommunications to the LAN through twisted pair wireline connections(126, 130, 132, 136, 122). The personal video recorder (108) and thecompact disc player (120) are coupled for data communications to the LANthrough a coaxial cable wireline connection (128, 140). The thermostat(114) and the desk lamp (118) are coupled for data communications to theLAN through a powerline connection (134, 138).

The exemplary devices of FIG. 1 are capable of reporting current valuesof supported device attributes and the exemplary devices of FIG. 1 arealso capable of receiving messages from other devices instructing thedevice to change values of supported attributes. The exemplary system ofFIG. 1 is capable generally of maintaining a device state history;identifying a device usage pattern in dependence upon the device statehistory, identifying a derived scenario in dependence upon the deviceusage pattern, and selecting a heuristic in dependence upon the derivedscenario. The heuristic typically has a tolerance. The system of FIG. 1is also capable generally of identifying a workflow in dependence uponthe selected heuristic and executing the workflow in dependence upon thetolerance.

A device state history is a data structure containing the history of thevalues of one or more attributes of one or more devices. In the exampleof FIG. 1, each device may maintain its own device state history andstore the device history in computer memory installed on the device orsingle device state history of all the devices in the network maybemaintained in computer memory accessible to application programmingimplementing workflow decision management that is installed on one ormore devices.

A device usage pattern is typically implemented as a data structurerepresenting a predetermined pattern of device usage for one or moredevices. That is, a data structure representing a pattern of deviceusage. A device usage pattern may represent a pattern of usage of asingle device or a pattern of usage of more than one device. The systemof FIG. 1 typically identifies a device usage pattern in dependence uponthe device state history by searching a plurality of stored device usagerecords for a device usage record that matches recent entries in thedevice state history.

The system of FIG. 1 is also capable of identifying a derived scenarioin dependence upon the identified device usage pattern. A derivedscenario is typically implemented as a data structure representing aparticular state of devices in a networked environment. Derivedscenarios are created in dependence upon actual past device usage withinthe networked environment and such derived scenarios often representscenarios of device usage of more than one device. The system of FIG. 1typically identifies a derived scenario by retrieving a derived scenarioID from a derived scenario table in dependence upon the identifieddevice usage pattern ID.

The system of FIG. 1 is also capable of identifying a heuristic independence upon the derived scenario. A heuristic represents asimplified solution directed at administering devices according to aparticular derived scenario. That is, a heuristic is a data structurerepresenting an approximate solution to a particular state of devices ina networked environment comprising the scenario.

The system of FIG. 1 is also capable of identifying a workflow independence upon the heuristic and executing the workflow. A workflow issoftware implementing a device controlling action that when executedchanges the values of one or more attributes of one or more devices.Executing workflows typically includes calling member methods in a CALobject for a device, downloading an OSGi bundle to a device, callingmember methods in a device class, sending a message to a device, or anyother method of executing a workflow as will occur to those of skill inthe art.

The arrangement of devices making up the exemplary system illustrated inFIG. 1 is for explanation, not for limitation. Data processing systemsuseful according to various embodiments of the present invention mayinclude additional servers, routers, other devices, and peer-to-peerarchitectures, not shown in FIG. 1, as will occur to those of skill inthe art. Networks in such data processing systems may support many datacommunications protocols, including for example, CEBus, X-10, LonTalk,HomePlug, HAVi, TCP/IP, HTTP, WAP, and others as will occur to those ofskill in the art. Various embodiments of the present invention may alsobe implemented in various computer environments such as for exampleCEBus, OSGi, and others that will occur to those of skill in the art.Although much of the present specification describes exemplaryembodiments of the present invention with particular reference to CEBus,the such descriptions are for explanation not for limitation. In fact,many environments and frameworks support workflow decision managementaccording to the present invention such as, for example, CEBus, HAVi,HomePlug, LonWorks, X-10, OSGi, as well as others that will occur tothose of skill in the art, and all such environments and frameworks arewithin the scope of the present invention.

Workflow decision management in accordance with the present invention isgenerally implemented with automated computing machinery installed onone or more workflow decision management compliant devices. For furtherexplanation, FIG. 2 sets forth a block diagram of an exemplary device(150) useful in implementing workflow decision management according toembodiments of the present invention. The device (150) of FIG. 2includes at least one computer processor (156) or ‘CPU’ as well asrandom access memory (168) (“RAM”). Stored in RAM (168) is an operatingsystem (154). Operating systems useful in computers according toembodiments of the present invention include Unix, Linux, Microsoft NT™,and many others as will occur to those of skill in the art. Operatingsystem (154) in the example of FIG. 2 is shown in RAM (168), but manycomponents of an operating system typically are stored in non-volatilememory (166) also.

Also stored in RAM is a workflow decision management application (162).The workflow decision management application is application computerprogramming generally capable of maintaining a device state history,identifying a device usage pattern in dependence upon the device statehistory, and identifying a derived scenario in dependence upon thedevice usage pattern. The workflow decision management application isalso generally capable of selecting a heuristic in dependence upon thederived scenario. The heuristic typically has a tolerance governing theexecution of workflows. The exemplary devices of FIG. 2 are also capableof identifying a workflow in dependence upon the derived scenario; andexecuting the workflow in dependence upon the tolerance. Methods ofworkflow decision management in accordance with the present inventioncan be implemented using many programming languages including CAL, OSGi,Java, C++, Smalltalk, C, Pascal, Basic, COBOL, Fortran, and so on, aswill occur to those of skill in the art.

The device (150) of FIG. 2 includes non-volatile computer memory (166)coupled through a system bus (160) to processor (156) and to othercomponents of the device (150). Non-volatile computer memory (166) maybe implemented as a hard disk drive (170), optical disk drive (172),electrically erasable programmable read-only memory space (so-called‘EEPROM’ or ‘Flash’ memory) (174), RAM drives (not shown), or as anyother kind of computer memory as will occur to those of skill in theart.

The exemplary device (150) of FIG. 2 includes a communications adapter(167) for implementing connections for data communications (184),including connections through networks, to other workflow managementcompliant devices (182), including servers, other workflow managementclient devices, and others as will occur to those of skill in the art.Communications adapters implement the hardware level of connections fordata communications through which local devices and remote devices orservers send data communications directly to one another and throughnetworks. Examples of communications adapters useful for workflowdecision management according to embodiments of the present inventioninclude modems for wired dial-up connections, Ethernet (IEEE 802.3)adapters for wired LAN connections, and 802.11b adapters for wirelessLAN connections.

The example device of FIG. 2 includes one or more input/output interfaceadapters (178). Input/output interface adapters in workflow managementcompliant devices implement user-oriented input/output through, forexample, software drivers and computer hardware for controlling outputto display devices (180) such as computer display screens, as well asuser input from user input devices (181) such as keyboards and mice.

FIGS. 3 and 4 are block diagrams illustrating exemplary data structuresuseful in implementing methods of workflow decision management accordingto aspects of the present invention. In this specification, the terms“field” and “data element,” unless the context indicates otherwise,generally are used as synonyms, referring to individual elements ofdigital data. Aggregates of data elements are referred to as “records”or “data structures.” Aggregates of records are referred to as “tables”or “files.” Aggregates of files or tables are referred to as“databases.”

The example of FIG. 3 includes a device record (150) that represents aworkflow decision management compliant device in accordance with thepresent invention. The exemplary device record (150) includes a deviceID field (302) uniquely identifying the device. The exemplary devicerecord (150) also includes an address field (304) containing the networkaddress of the device. The exemplary device record (150) includes anattribute field (306). The attribute field contains the value of aparticular attribute of a device indicating a device state such as on,off, a volume setting, and so on. Although only one attribute field isshown in the example of FIG. 3, this for simplicity of explanation. Manyworkflow decision management compliant devices support more than oneattribute as will occur to those of skill in the art.

The example of FIG. 3 includes an exemplary device state record (330)that represents the allowable device states of a particular device. Thedevice state record includes a device ID field (302) uniquelyidentifying the device for which the device state record representsacceptable device states. The device state record (330) also includes adevice state ID field (316) uniquely identifying the device state. Thedevice state record (330) also includes a description field (339)containing a description of the acceptable states or attribute values ofthe device.

The example of FIG. 3 includes a devices state history (314). The devicestate history is a data structure containing the history of the state ofone or more devices. That is, the current as well as past values ofattributes of a device. Records in the exemplary device state history(314) include a device ID (302) uniquely identifying the device forwhich the device state is recorded. Records of the exemplary devicestate history also include a device state ID field (316) uniquelyidentifying acceptable device states for the device. Records of theexemplary device state history (314) include a value field (318)containing the value of a particular attribute of the device. As statedabove, typical devices support more than one attribute and thereforetypical records of device state histories include a plurality of valuefields containing the values of the supported attributes. Records of theexemplary device state history include a time stamp field (320)containing date and time information identifying the date and time thata particular device attribute of a particular device had a particularvalue.

The example of FIG. 3 includes a device usage record (328) thatrepresents a predetermined pattern of device attributes for a device.That is, a device usage is a data structure used to identify whether thestates of the devices in a particular networked environment conform to apredetermined pattern. To determine whether the state of current devicesin a particular networked environment conform to a predeterminedpattern, recent entries in the device state history compared with aplurality of device usage. If the comparison results in a match, it isinferred that the state of the devices in the particular networkedenvironment conform to a predetermined pattern.

The exemplary devices usage (328) includes a usage ID (376) uniquelyidentifying a particular predetermined pattern of device usage. Theexemplary device usage of FIG. 3 includes a device ID (302) uniquelyidentifying a particular device. The device usage (328) also includes adevice state ID (326) uniquely identifying the acceptable device statesfor the particular device. The exemplary device usage (328) includes avalue field (318) containing the value of a particular supportedattribute of the device.

The example of FIG. 3 includes a usage record (332) that identifies anddescribes a particular pattern of device usage in the networkedenvironment. The usage record (332) includes usage ID (334) thatuniquely identifies the pattern of device usage, and a description field(336) that contains a description of the pattern of device usagerepresented by the usage record (332).

The example of FIG. 3 includes a scenario record (344) that represents aparticular scenario of device usage consistent with an identifiedpredetermined device usage pattern. Scenarios (344) are predeterminedand predefined generally from many users in many networked environments.That is, they are not created from the actual device usage in thenetworked domain in which they are implemented. When the current statesof a device conform to a predetermined pattern of device usage, thecurrent states of a device may also conform to one of a plurality ofscenarios. The exemplary scenario record (344) of FIG. 3 includes ascenario ID field (346) uniquely identifying the scenario. The exemplaryscenario record (344) of FIG. 3 includes a workflow ID (340) identifyinga workflow for execution when the current device states in a particularnetworked environment identify a scenario. Although the scenario recordof FIG. 3 includes a single workflow ID field, this for simplicity ofexplanation, not for limitation. In many embodiments of the presentinvention, a particular scenario supports the execution of more than oneworkflow. The scenario (344) of FIG. 3 also contains a description field(350) that contains a description of the scenario.

The example of FIG. 3 includes a workflow record (338) that represents aparticular device controlling action or a set of device controllingactions. A workflow is software implementing a device controlling actionthat when executed changes the values of one or more attributes of oneor more devices in accordance with the present invention. The exemplaryworkflow record (338) includes a workflow ID (340) uniquely identifyingthe workflow. The exemplary workflow record (338) of FIG. 3 alsoincludes a sequence field (342) identifying whose value is used toexecute this workflow in a particular sequence of execution of aplurality of workflows. That is, when more than one workflow is executedfor a scenario, the value of the sequence field is used to sequence theexecution of the plurality of workflows. Workflows can be implementedusing CAL, OSGi, Java, C++, Smalltalk, C, Pascal, Basic, COBOL, Fortran,and so on, as will occur to those of skill in the art.

The example of FIG. 3 includes a workflow session (362) that representsan instance of an executed workflow. The exemplary workflow session(362) includes a workflow session ID (364) uniquely identifying theworkflow session and a workflow ID (340) identifying the executedworkflow. The exemplary workflow session also includes a user sessionstate ID (366) uniquely identifying the particular user session forwhich the workflow is executed. The exemplary workflow session alsoincludes a message ID (368) identifying a message sent to a device toeffect the workflow. That is the message send to a device instructingthe device to change the value of a particular attribute. Sending suchmessages to the device, in some embodiments, effect changes in devicestatus and therefore, carry out the workflow. The exemplary workflowsession (362) includes a user ID (370) identifying the user on whosebehalf the workflow is executed and a role ID field (372) identifyingthe security role of the user.

The example of FIG. 3 includes a derived scenario (352) that representsa particular scenario of device usage in the networked domain. Derivedscenarios are created in dependence upon the actual device usage withinthe networked environment. Derived scenarios (352) have two importantdistinctions from scenarios (344). First, the derived scenarios arecreated in dependence upon the device usage of the devices within thenetworked environment and therefore reflect scenarios of device usage ofthe particular networked environment from which they are derived ratherthan canned or off the shelf scenarios. Second, derived scenarios havean associated tolerance (360) which is a rule set that governs theexecution of workflows executed in dependence upon identifying thederived scenario.

The exemplary derived scenario (352) of FIG. 3 includes a derivedscenario ID field (354) uniquely identifying the derived scenario. Thederived scenario (352) record contains a description field (358)containing a description of the derived scenario.

The example of FIG. 3 includes a tolerance record (360) that representsa rule set governing the execution of a workflow executed in dependenceupon a selected heuristic. Often a tolerance is a subset of the range ofacceptable attribute values that a device supports. For example, athermostat may support attribute values that will, if set, eventuallydamage either the thermostat itself or other devices. A tolerance istherefore often designed to govern the execution of workflows such thatdevice usage is not harmful to devices within the networked environment.The exemplary tolerance (360) of FIG. 3 includes a tolerance level IDfield (362) uniquely identifying the tolerance.

The example of FIG. 3 includes a device threshold record (308) thatrepresents the threshold minimum and threshold maximum attribute valuesthat device will support. The exemplary device threshold record (308) ofFIG. 3 includes a device ID (302) identifying the device for which thethresholds are valid. The exemplary device threshold record alsoincludes MAX field (310) containing the maximum attribute value that thedevice will support and a MIN field (312) that includes the minimumattribute value that the device will support.

The example of FIG. 3 includes a user record (374) representing a userfor which workflows are performed to affect device status. Usersaccording to aspects of workflow decision management of the presentinvention are not limited to human users, but also include processes aswill occur to those of skill in the art. The exemplary user record (374)of FIG. 3 includes a user ID (376) uniquely identifying the user and arole ID (378) uniquely representing the role of the user. A role issecurity role for the user such as a systems administrator, a guest, andso on.

The example of FIG. 3 also includes a user session state (382) thatrepresents a session for a user. A session for a user indicationscurrent workflow decision management being executed on the user'sbehalf. The user session state (382) of FIG. 3 includes a session stateID (384) that uniquely identifies the user session state and a messageID (386) that identifies a message sent to give effect to a particularworkflow identified in a workflow session and executed on behalf of theuser. The user session state also includes a user ID (376) identifyingthe user on whose behalf the workflow is executed and a role ID (378)identifying the role of the user.

FIG. 4 is a block diagram of more data structures useful in workflowdecision management according to embodiments of the present invention.The example of FIG. 4 includes a role record (402) that represents asecurity role for a user. The exemplary role record (402) of FIG. 4includes a role ID (378) that uniquely identifies a security role.

The example of FIG. 4 includes a role device privileges record (404)that representing the privileges assigned to a particular role for adevice. For example, some security roles have only limited access tosome devices. The role device privileges record (404) includes a roleprivileges ID field (406) uniquely identifying the role deviceprivileges. The exemplary role device privileges record (404) of FIG. 4includes a privileges ID (408) identifying an allowable privilege and arole ID (378) identifying a particular security role having theprivilege.

The example of FIG. 4 includes a privilege record (415) representing aparticular privilege. The exemplary privilege record (415) includes aprivilege ID field (436) identifying the privilege and a descriptionfield (410) containing a description of the privilege. The exemplaryprivilege record (415) includes a read flag (412) and a write flag (414)containing a Boolean indication of read and write privileges.

The example of FIG. 4 includes a message record (416) representing amessage. The message record (416) includes a message ID field (386)uniquely representing the message. The example message (416) of FIG. 4also includes an origin address field (418) containing the networkaddress of the device originating the message and a destination addressfield (420) containing the network address of the device receiving themessage.

The example of FIG. 4 includes a device privilege record (422) thatrepresents an available privilege appropriate for a device. Theexemplary device privilege record (422) of FIG. 4 includes a deviceprivilege ID (424) uniquely identifying the device privilege and adevice ID (302) identifying the device. The exemplary device privilegerecord (422) includes a privilege ID (437) identifying an privilegeappropriate for the device.

The example of FIG. 4 includes a heuristic record (338). In computerscience the term ‘heuristic’ typically means a simplified solution or aneducated guess that reduces the search for solutions in domains that aredifficult and poorly understood. Unlike algorithms, heuristics often donot guarantee optimal, or even feasible, solutions and are often usedwith no theoretical guarantee. In the case of workflow decisionmanagement according to embodiments of the present invention, aheuristic record represents a simplified solution directed atadministering devices according to a particular derived scenario. Thatis, a heuristic is a data structure representing an approximate solutionto a particular scenario. For example, a device usage pattern maydemonstrate that a ceiling fan is operating at its maximum capacity andthermostat is set to a target temperature of 72 degrees Farenheit.However, the room temperature is over 80 degrees Farenheit. One derivedscenario representing this device usage pattern may be that thetemperature outside the window of the room is over 90 degrees Farenheit.In this specification, a heuristic is a data structure representing anapproximate solution to the problem. In this example, a heuristic recordrepresenting ‘cool the room’ may have associated workflows that giveeffect to the heuristic by administering devices to cool the room, suchas by calling member methods for the thermostat to reduce the thermostatsetting to 68 degrees Farenheit.

The exemplary heuristic record of FIG. 4 includes a heuristic ID (341)uniquely identifying the heuristic. The exemplary heuristic record (339)of FIG. 4 includes a workflow ID field (340) identifying a workflow thatwhen executed gives effect to the heuristic. The exemplary heuristicrecord of FIG. 4 also includes a tolerance ID (356) identifying anassociated tolerance for workflows executed in dependence upon theheuristic. The workflow associated with the heuristic is executed independence upon the associated tolerances of the heuristic.

FIG. 5 is a block diagram illustrating an exemplary relationship amongthe data structures of FIGS. 3 and 4. In the example of FIG. 5, thedevice record is related one-to-many to the identified device usagerecord (328) through the device ID field (302 on FIG. 3) used as aforeign key. The identified device usage record (328) is relatedmany-to-one to the usage record (332) through the usage ID field (376 onFIG. 3) used as a foreign key. The device record (150) is relatedone-to-many to the device threshold record (308) through the device IDfield (302 on FIG. 3) used as a foreign key.

In the example of FIG. 5, the device record (150) is related one-to-manyto the device state record (330) through the device ID field (302 onFIG. 3) used as a foreign key. The device state record (330) is relatedone-to-many to the device state history record (314) through the devicestate ID field (316 on FIG. 3) used as a foreign key. The device statehistory record (314) is related many-to-one to the device record (150)through the device ID field (302 on FIG. 3) used as a foreign key.

In the example of FIG. 5, the device record (150) is related one-to-manyto the scenario record (344) through the device ID field (302 on FIG. 3)used as a foreign key. The scenario record (344) is related many-to-manyto the heuristic record (339) through the heuristic ID field (341 onFIG. 4). The heuristic record is related one-to-many to the workflowrecord (338) through a workflow ID field (340 on FIG. 3) used as aforeign key. The workflow record (338) is related one-to-many to theworkflow session (362) through the workflow ID field (340 on FIG. 3)used as a foreign key.

In the example of FIG. 5, the device record (150) is related one-to-manyto the derived scenario record (352) through the device ID field (302 onFIG. 3) used as a foreign key. The derived scenario record (352) isrelated many-to-many to the heuristic record (339) through the heuristicID field (341 on FIG. 4). The heuristic record (339) is relatedmany-to-one to the tolerance record (360) through the tolerance ID field(356 on FIG. 4) used as a foreign key.

In the example of FIG. 5, the device record (150) is related one to manywith the device privileges record (422) through the device ID field (302on FIG. 3) used as a foreign key. The device privileges record (422) isrelated many-to-one through to the privileges record (415) through theprivilege ID field (437 on FIG. 4) used as a foreign key. The privilegesrecord (415) is related one-to-many to the role device privileges record(404) through the privilege ID field (436 on FIG. 4) used as a foreignkey. The role device privileges record (404) is related many-to-one tothe role record (402) through a role field (378 on FIG. 4) used as aforeign key.

In the example of FIG. 5, the user record (374) is related many-to-onethrough to the role record (402) through the role ID field (378 on FIG.4) used as a foreign key. The user record (374) is related to the usersession state (382) one-to-many through the user ID field (376 on FIG.3) used as a foreign key. In the example of FIG. 5, the user sessionstate (382) is related many-to-one to the message record (416) throughthe message ID field (386 on FIG. 4) used as a foreign key. In theexample of FIG. 5, the user session state (382) is related one-to-manyto the workflow session (362) through the user session state ID (384 onFIG. 3) used as a foreign key.

Workflow Decision Management with Heuristics

FIG. 6 sets forth a data flow diagram illustrating an exemplary methodfor workflow decision management. The method of FIG. 6 includesmaintaining (602) a device state history (314). As discussed above, thedevice state history is a data structure containing the history of thevalues of one or more attributes of one or more devices. A device statehistory for a single device can be maintained in computer memory on thedevice itself or a single device state history for many devices in thenetworked environment can be maintained in computer memory accessible toapplication programming implementing the method of FIG. 6.

In the method of FIG. 6, maintaining (602) a device state history (314)includes recording a plurality of attribute values (306) for a device(150). In the example of FIG. 6, each time an attribute value (306) of adevice (150) is changed, the change is recorded by creating a new entryin a device state history. In some such embodiments, the latest entry inthe device state history (314) represents the current state of thedevice. In some embodiments, workflow decision management devices areconfigured to report to application programming implementing a devicestate manager with each change in an attribute value and the devicestate manager creates a new entry in a device state history recordingthe change in attribute value.

The method of FIG. 6 also includes identifying (604) a device usagepattern (328) in dependence upon the device state history (314). Asdiscussed above, a device usage record represents a predeterminedpattern of device usage and includes a collection of device attributevalues defining the device usage pattern. In the method of FIG. 6,identifying (604) a device usage pattern (328) in dependence upon thedevice state history (314) includes comparing the device state history(314) with a plurality of device usage patterns records (329). In theexample of FIG. 6, a window of the entries of the device state history(314) representing recent device states is compared with device usagerecords (329) in a device usage pattern database (616) to identify amatching an identified device usage record (328). If such a matching anidentified device usage record (328) exists, the current state ofdevices within a networked environment conform to a device usage patternrepresented by the record.

As will occur to those of skill in the art, in typical embodiments, thevalues of the entries in the device state history do not have to beexactly the same as the values of the device usage records to identify amatching device usage record. In fact, the values of the entries of thedevice state history will often not be the exactly the same as thevalues of the device usage records when a matching record is identified.The degree to which the values of the entries in the device statehistory must be similar to the values of the device usage records to beconsidered a match will vary according to factors such as tolerances andmethods used to used to compare the device state history with the deviceusage records, predefined tolerances for identifying a match, as well asother numerous factors that will occur to those of skill in the art.

The method of FIG. 6 also includes identifying (606) a derived scenario(352) in dependence upon the identified device usage pattern (328). Asdiscussed above, a derived scenario (352) represents a particularscenario created in dependence upon actual device usage within thenetworked environment. Derived scenarios (352) have at least oneimportant distinction from other canned scenarios or off-the-shelfscenarios. The derived scenarios are created in dependence upon theactual past device usage of the devices within the networked environmentand therefore reflect scenarios of device usage of the particularnetworked environment.

In the method of FIG. 6, identifying (606) a derived scenario (352) independence upon the identified device usage pattern (328) furthercomprises retrieving a derived scenario ID from a derived scenariotable. In the example of FIG. 6 a derived scenario table (609) includesa plurality of derived scenario IDs (354) indexed by device usage IDs(330) identifying predefined device usage patterns. Identifying (606) aderived scenario (352) in dependence upon the identified device usagepattern (328) therefore includes retrieving a derived scenario ID from aderived scenario table in dependence upon the device usage ID (330) ofthe identified device usage record (328).

In the method of FIG. 6, identifying (606) a derived scenario (352) independence upon the identified device usage pattern (328) includesidentifying a derived scenario (352) in dependence upon a rule (608). Arule (608) governs the identification of a particular derived scenarioamong a plurality of derived scenarios when more than one derivedscenario associated with a single device usage pattern exists. Considerthe example of a user cooking in a networked kitchen. The states of thedevices in a living room match a device usage pattern that the user iscooking. However, more than one scenario corresponds with the deviceusage pattern as the user may be cooking breakfast, cooking lunch, orcooking supper. An exemplary rule identifying a scenario is: If time ofday is between 4:30 p.m. and 7:30 p.m. and device usage patternidentifies a cooking scenario, then user is cooking supper.

The method of FIG. 6 also includes selecting (607) a heuristic (339) independence upon the derived scenario (609). As discussed above, aheuristic record represents a simplified solution directed atadministering devices according to a particular derived scenario. Thatis, a heuristic is a data structure representing an approximate solutionto a particular state of devices in a networked environment. Forexample, a device usage pattern may be identified for a ceiling fanoperating at its maximum capacity, a thermostat set to a targettemperature of 72 degrees Fahrenheit, but the room temperature is stillover 80 degrees Fahrenheit. One derived scenario representing thisdevice usage pattern may be that the temperature outside the window ofthe room is over 90 degrees Fahrenheit. An example heuristicrepresenting an approximate solution is implemented as a heuristicrecord representing ‘cool the room.’ Such a heuristic has associated oneor more workflows that administer devices to carry out the approximatesolution. Continuing with the same example, workflows that turn on afan, draw shades, and lower the thermostat by one degree every 10minutes carry out an approximate solution to cool the room. Those ofskill in the art will recognize that the heuristics provide a vehicle toseparate the problem from the solution and advantageously provideincreased granularity in approaching executing workflows to administerdevices in response to identifying derived scenarios.

In the method of FIG. 6, selecting (607) a heuristic (339) in dependenceupon the derived scenario (352) includes reading a heuristic ID (359)from a derived scenario record (352). In other embodiments, selecting(607) a heuristic (339) in dependence upon the derived scenario (352)includes retrieving a heuristic ID from a heuristic table.

In the example of FIG. 6, the heuristic (339) also has an associatedtolerance (356). As discussed above, a tolerance is a rule set governingthe execution of workflows executed in dependence upon the selectedheuristic. Often a tolerance is a subset of the range of acceptableattribute values that a device supports. Such tolerances are oftendesigned to prevent the execution of workflows from damaging deviceswithin the networked environment.

The method of FIG. 6 also includes identifying (612) a workflow (338) independence upon the heuristic (339). As discussed above, a workflow issoftware implementing a device controlling action that when executedchanges the values of one or more attributes of one or more devices inaccordance with the present invention. In the method of FIG. 6,identifying (612) a workflow (338) in dependence upon the selectedheuristic comprises retrieving a workflow ID (340) from a heuristicrecord (339).

The method of FIG. 6 also includes executing (614) the workflow (338) independence upon the tolerance (356). As discussed above, a tolerancerepresents a rule governing the execution of a workflow. Often atolerance is a subset of the range of acceptable attribute values that adevice supports. Such tolerances are often designed to prevent theexecution of workflows from damaging devices within the networkedenvironment.

Consider the following example. A networked home has a number of devicesthat are used to cool the west wing of the home. These devices include afan, an air conditioner, and automatic shades. However, the automaticshades are currently not working and they currently will not closeproperly. A workflow decision management application operating accordingto the present invention has identified a scenario within a home networkdemonstrating that the west wing of the home is too warm and identifiedan appropriate heuristic to cool the wing. The workflow decisionmanagement application identifies and executes a workflow associatedwith the heuristic to cool the wing that includes reducing thethermostat for the air conditioner, increasing fan speed and closing theautomatic shades.

Because the automatic shades are not working properly, the workflow doesnot reduce the temperature in the west wing sufficiently and soonthereafter the scenario that the room is too hot is again identified andagain the same heuristic is identified. The same workflow is againidentified and executed. By providing a tolerance for the execution ofthe workflow that defines a minimum tolerance value allowed for thethermostat, the air conditioner is spared from being overworked to thepoint of damage. That is, tolerances provide some boundaries for theexecution of workflow preventing devices from being damaged byunforeseen problems with the execution of a workflow, such as in thiscase, the automatic shades not working properly. These tolerance valuesare often designed as a subset of the actual values that devicessupport. Such design advantageously recognizes that devices oftensupport attribute values that will ultimately lead to damaging thedevice.

In the method of FIG. 6, executing (614) the workflow (338) independence upon the tolerance (356) further comprises sending a messageto a device instructing the device to change the value of an attribute.In some such examples, a device receiving such a method can effect thechange in value of the device by calling a member methods in a deviceclass representing the device such as, for example,SomeDeviceClass.setAtrribute( ) parameterized with an attribute value.

It will be understood from the foregoing description that modificationsand changes may be made in various embodiments of the present inventionwithout departing from its true spirit. The descriptions in thisspecification are for purposes of illustration only and are not to beconstrued in a limiting sense. The scope of the present invention islimited only by the language of the following claims.

1. A method for workflow decision management, the method comprising: maintaining a device state history; identifying a device usage pattern in dependence upon the device state history; identifying a derived scenario in dependence upon the device usage pattern; selecting a heuristic in dependence upon the derived scenario; wherein the heuristic has a tolerance; identifying a workflow in dependence upon the selected heuristic; and executing the workflow in dependence upon the tolerance.
 2. The method of claim 1 wherein maintaining a device state history further comprises recording a plurality of attribute values for a device.
 3. The method of claim 1 wherein identifying a device usage pattern in dependence upon the device state history further comprises comparing the device state history with a plurality of device usage patterns records.
 4. The method of claim 1 wherein identifying a derived scenario in dependence upon the device usage pattern further comprises retrieving a derived scenario ID from a derived scenario table.
 5. The method of claim 1 wherein selecting a heuristic in dependence upon the derived scenario further comprises reading a heuristic ID from a derived scenario record.
 6. The method of claim 1 wherein selecting a heuristic in dependence upon the derived scenario further comprises retrieving a heuristic ID from a heuristic table.
 7. The method of claim 1 wherein identifying a workflow in dependence upon the selected heuristic comprises retrieving a workflow ID from a heuristic record.
 8. The method of claim 1 wherein executing the workflow in dependence upon the tolerance further comprises sending a message to a device.
 9. The method of claim 1 wherein executing the workflow in dependence upon the tolerance further comprises calling a member method in a device class.
 10. A system for workflow decision management, the system comprising: means for maintaining a device state history; means for identifying a device usage pattern in dependence upon the device state history; means for identifying a derived scenario in dependence upon the device usage pattern; means for selecting a heuristic in dependence upon the derived scenario; wherein the heuristic has a tolerance; means for identifying a workflow in dependence upon the selected heuristic; and means for executing the workflow in dependence upon the tolerance.
 11. The system of claim 10 wherein means for maintaining a device state history further comprises means for recording a plurality of attribute values for a device.
 12. The system of claim 10 wherein means for identifying a device usage pattern in dependence upon the device state history further comprises means for comparing the device state history with a plurality of device usage patterns records.
 13. The system of claim 10 wherein means for identifying a derived scenario in dependence upon the device usage pattern further comprises means for retrieving a derived scenario ID from a derived scenario table.
 14. The system of claim 10 wherein means for selecting a heuristic in dependence upon the derived scenario further comprises means for reading a heuristic ID from a derived scenario record.
 15. The system of claim 10 wherein means for selecting a heuristic in dependence upon the derived scenario further comprises means for retrieving a heuristic ID from a heuristic table.
 16. The system of claim 10 wherein means for identifying a workflow in dependence upon the selected heuristic further comprises means for retrieving a workflow ID from a heuristic record.
 17. The system of claim 10 wherein means for executing the workflow in dependence upon the tolerance further comprises means for sending a message to a device.
 18. The system of claim 10 wherein means for executing the workflow in dependence upon the tolerance further comprises means for calling a member system in a device class.
 19. A computer program product for workflow decision management, the computer program product comprising: a recording medium; means, recorded on the recording medium, for maintaining a device state history; means, recorded on the recording medium, for identifying a device usage pattern in dependence upon the device state history; means, recorded on the recording medium, for identifying a derived scenario in dependence upon the device usage pattern; means, recorded on the recording medium, for selecting a heuristic in dependence upon the derived scenario; wherein the heuristic has a tolerance; means, recorded on the recording medium, for identifying a workflow in dependence upon the selected heuristic; and means, recorded on the recording medium, for executing the workflow in dependence upon the tolerance.
 20. The computer program product of claim 19 wherein means, recorded on the recording medium, for maintaining a device state history further comprises means, recorded on the recording medium, for recording a plurality of attribute values for a device.
 21. The computer program product of claim 19 wherein means, recorded on the recording medium, for identifying a device usage pattern in dependence upon the device state history further comprises means, recorded on the recording medium, for comparing the device state history with a plurality of device usage patterns records.
 22. The computer program product of claim 19 wherein means, recorded on the recording medium, for identifying a derived scenario in dependence upon the device usage pattern further comprises means, recorded on the recording medium, for retrieving a derived scenario ID from a derived scenario table.
 23. The computer program product of claim 19 wherein means, recorded on the recording medium, for selecting a heuristic in dependence upon the derived scenario further comprises means, recorded on the recording medium, for reading a heuristic ID from a derived scenario record.
 24. The computer program product of claim 19 wherein means, recorded on the recording medium, for selecting a heuristic in dependence upon the derived scenario further comprises means, recorded on the recording medium, for retrieving a heuristic ID from a heuristic table.
 25. The computer program product of claim 19 wherein means, recorded on the recording medium, for identifying a workflow in dependence upon the selected heuristic further comprises means, recorded on the recording medium, for retrieving a workflow ID from a heuristic record.
 26. The computer program product of claim 19 wherein means, recorded on the recording medium, for executing the workflow in dependence upon the tolerance further comprises means, recorded on the recording medium, for sending a message to a device.
 27. The computer program product of claim 19 wherein means, recorded on the recording medium, for executing the workflow in dependence upon the tolerance further comprises means, recorded on the recording medium, for calling a member computer program product in a device class. 